1. Field of the Invention
The present invention relates generally to a method and system for establishing, changing and closing Session Initiation Protocol (SIP) sessions between SIP User Agents (UAs) in an SIP-based service environment. More particularly, the present invention relates to a method and system for integrating a session in progress on an SIP UA into a different independent session in progress on another SIP UA in an SIP-based service environment.
2. Description of the Related Art
In a conventional SIP-based service environment, if a session in progress on a second SIP UA is integrated into a different independent session in progress on a first SIP UA, the session in progress on the second SIP UA is closed and the session in progress on the first SIP UA is updated to include the session in progress on the second SIP UA.
This integrating operation may be performed by a session integration request from the first SIP UA, or a session integration request from the second SIP UA. The method of integrating sessions at the request of the first SIP UA may be embodied by the conventional SIP signaling.
FIG. 1 is a diagram illustrating a conventional process of integrating sessions at the request of a first SIP UA. Only those components necessary for the process of integrating sessions between SIP UAs are shown in FIG. 1. An SIP/IP core network in an SIP-based service environment is excluded. In the SIP-based service environment, the SIP/IP core network provides a basic framework for transmitting and receiving all SIP requests and SIP responses between SIP entities. However, FIG. 1 focuses on interactions and operations between the SIP UAs and an SIP server.
It is assumed in FIG. 1 that first and second SIP UAs belong to a user A and a third SIP UA belongs to another user B. Also, it is assumed that user A and user B exchange audio and video with each other. User B transmits/receives both audio and video with the third SIP UA, while user A transmits/receives only audio with the first SIP UA and only video with the second SIP UA. For that purpose, user B establishes one SIP session supporting both audio and video between the third SIP UA and the SIP server, and user A establishes an audio session between the first SIP UA and the SIP server and a video session between the second SIP UA and the SIP server.
Based on the assumptions described above, with reference to FIG. 1, a description is provided of a process of integrating the video session in progress on the second SIP UA into the audio session in progress on the first SIP UA at the request of the first SIP UA.
Referring to FIG. 1, in step 101, the first SIP UA sends an update request for the audio session to the SIP server in order to integrate the audio session established to the SIP server and the video session between the second SIP UA and the SIP server. To request update of the audio session, the first SIP UA sends a Re-request message (hereinafter referred to as a “Re-INVITE message”) to the SIP server. Since the updated session should support both audio and video, the Re-INVITE message includes Session Description Protocol (SDP) bodies for the audio and the video. In addition, the Re-INVITE message includes a Replaces header in order to release the video session in progress between the second SIP UA and the SIP server after the audio session is updated between the first SIP UA and the SIP server. The Replaces header has a dialog-id that is generated when the video session is established between the second SIP UA and the SIP server. The dialog is shared by two SIP UAs by exchanging SIP messages with each other, and each dialog-id has call-id, from-tag and to-tag, which are commonly included in SIP messages exchanged to create the dialog.
In step 103, upon receipt of the Re-INVITE message, the SIP server sends an Accept Response message (hereinafter referred to as a “200 OK message”) to the first SIP UA in response to the received Re-INVITE message. In step 105, if the first SIP UA receives the 200 OK message, the audio session between the first SIP UA and the SIP server is updated into an audio-video integrated session at the request of the first SIP UA.
In step 107, the SIP server sends a Close message (hereinafter referred to as a “BYE message”) to the second SIP UA in order to close the dialog indicated by the Replaces header included in the received Re-INVITE message. If the second SIP UA sends a 200 OK message to the SIP server in response to the BYE message in step 109, the video session between the second SIP UA and the SIP server is released in step 111.
Conventionally, when there is an intention to integrate SIP sessions in progress on different SIP UAs into a single SIP session, the first SIP UA should send a Re-INVITE message with a Replaces header to the SIP server. In the conventional technology, because the session integration request is equivalent to a session update request, an SIP UA requesting session integration is also identical to an SIP UA requesting session update.
However, even when the second SIP UA requests the session integration, a session update request must be made by the first SIP UA joining the relevant session. Specifically, even if the second SIP UA requests the session integration, a session update request from the first SIP UA to the SIP server should be made. SIP defines a REFER message in order to enable a recipient of the REFER message to send an INVITE message to the other SIP UA. However, the SIP UA, which received the REFER message, can generate and send a new INVITE message based on the REFER message, but cannot generate a Re-INVITE message.